REMARKS 

In the February 12, 2004, fourth Office Action in this application, the United States 
Patent and Trademark Office withdrew the rejection of Claims 4, 9, 13, and 14-19 under 
35 U.S.C. § 112, second paragraph, as being indefinite. Claims 1, 3-5, 7-9, and 11-14, 16-19 
were rejected under 35 U.S.C. § 103(a) as being unpatentable in view of the teachings of U.S. 
Patent No. 5,619,710, issued to Travis, Jr., et al. (hereinafter "Travis et al."), and ftirther in view 
of the teachings of U.S. Patent No. 6,557,165, issued to Nagashima et al. (hereinafter 
"Nagashima et al."). Claims 2, 6, 10, and 15 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable in view of the teachings of Travis etal. taken in view of the teachings of 
Nagashima et al. and ftarther in view of the teachings of U.S. Patent No. 5,737,611, issued to 
Vicik (hereinafter "Vicik"). 

Prior to discussing in detail why applicant believes that all of the claims in this 
application are allowable, a brief description of applicant's invention and a brief description of 
the teachings of the cited and applied references are provided. The following background and 
the discussions of the disclosed embodiments of applicant's invention and the teachings in the 
cited and applied references are not provided to define the scope or interpretation of any of the 
claims of this appHcation. Instead, such discussions are provided to help the Office better 
appreciate important claim distinctions discussed thereafter. 
Background of the Invention 

Programs are typically created in an application development environment using an 
application development language. An application development environment is an integrated 
suite of applications for use by software developers to create programs. Typical components of 
application development environments include a compiler, a file browsing system, a debugger, 
and a text editor for use in creating programs. An application development language is a 
computer language designed for creating programs. 
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As programs have become increasingly complex, programming environments are 
becoming a factor in the length of time it takes to create new programs and the number of bugs 
that occur as new programs are executed in conjunction with other programs. Traditionally, 
programs are developed in a linear manner. Unfortunately, a linear programming environment is 
often undesirable when highly complex computer programs that must run concurrently with 
other programs are to be developed. Another programming environment is the message-driven 
environment. In a message-driven programming environment, different objects interface with 
other objects via messages. Such messages typically are complex structures. To use such 
messages, the context must be unpacked from a message prior to the execution of an action. The 
message-driven programming environment as well as the linear programming environment are 
fragile and render development of programs that must run concurrently with other programs 
potentially more difficult and bug-laden than is desired. 
Summary of the Invention 

The present invention as summarized below focuses on an application development 
environment, which in other words is a programming environment. Applicant's invention is 
directed to improving the development of programs so that programs may be developed in a 
more efficient and bug-free manner. To solve or to reduce the foregoing problems, applicant's 
invention provides an asynchronous programming environment. More specifically, applicant's 
invention provides a dynamic object storage scheme for storing a plurality of objects, a dynamic 
dispatch scheme based on the plurality of objects, and an object recognition scheme to describe 
the plurality of objects. The dynamic object storage scheme stores the plurality of objects so that 
each object can be accessed as necessary by different threads within the asynchronous 
programming environment. The dynamic object storage scheme is dynamic in that objects can 
be created and removed as necessary during the execution of tasks within the asynchronous 
programming environment. The dynamic dispatch scheme is designed to invoke an action based 
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on the plurality of objects stored by the dynamic object storage scheme. Each action that is 
invoked by the dynamic dispatch scheme falls into one of a plurality of categories. Actions may 
be classified differently at different times. 

The plurality of categories include three categories — actions needing precisely one 
object, actions needing more than one object, or actions not needing an object at all. Actions 
needing precisely one object include message handlers, and other actions that do not need any 
object for their execution are generally used to create objects, such as default constructors and 
real-time routines. Actions that require multiple objects for their dispatch generally combine 
objects and perform tasks as designed by the programmer. 

Other aspects of the present invention include an object recognition scheme that describes 
the plurality of objects stored by the dynamic object storage scheme. The description of objects 
allows the asynchronous programming environment to determine whether a described object fits 
the needs of an application programming interface. In other words, when an application 
programming interface is presented to the asynchronous programming environment, it is not 
always clear which objects in a depository of objects fit the presented application programming 
interface. The object recognition scheme of the present invention allows one or more objects to 
be identified, thereby determining the suitability of one or more objects to the requirements of 
the application programming interface. 

Unlike prior programming environments, an asynchronous programming environment 
allows thread-agnostic programs to be developed. Such programs have symmetric 
multithreading capabilities, i.e., they can be scaled to use the most of available processor 
processing power. Symmetric multithreading is expected to reduce instruction cache misses on 
hardware implementations that handle multiple instruction streams at once. An asynchronous 
programming environment is more efficient than a message-driven programming environment 
because execution is driven via presence of objects so that little or no translation is needed to 
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recover context of execution. These attributes of an asynchronous programming environment 
allow programs to be developed in a more efficient and more bug-free manner. 
Summary of Travis et al. 

Travis et al. is directed to a system for invoking a method of an application across a 
network. The network of Travis et al. contains several platforms connected by the network. 
Each platform includes a central processing unit and memory. Running on each central 
processing unit of each platform is an operating system (e.g., VMS, ULTRIX, and MS-DOS), 
applications, and an application control architecture services (ACAS) software component. The 
ACAS software components of the various platforms of Travis et al., via an object-oriented 
technique, allow one application on one platform to invoke a method of another application on 
another platform. The memory of each platform contains information for a global class database 
which is shared by all platforms over the network. 

The system of Travis et al. organizes applications, data of applications, and operations on 
data of applications into object-oriented classes, which include class objects, method objects, and 
instance objects. An example of an instance object is a specific file, such as a file called 
MYFILE. The file MYFILE is operated on by a specific WRITE application. Because MYFILE 
is a specific file, it is not handled by the ACAS software components. MYFILE belongs to a 
class of compafible files, such as ASCII_FILE, which is handled by the ACAS software 
components. Similarly, the specific WRITE application is not handled by the ACAS software 
components. Instead, the specific WRITE application belongs to a class of applications called 
ALLWRITE, which in turn is handled by the ACAS software components. Applications can be 
characterized by the class objects to which the applications belong, by the method objects which 
support the operations in a particular application, and by instance objects upon which the method 
objects can operate. 
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Each instance object is associated with a class object. An instance object is manipulated 
by one class object (a first application) sending a message to another class object (a second 
application). The message might be an action, such as EDIT, READ, or PRINT. Messages are 
supported by the class objects. This means that the interpretation of a message depends upon the 
classes to which the instance objects in that message belong. For example, a PRINT message 
may be interpreted differently if the instance object is a text file in a class object TEXT__FILES 
as opposed to an instance object that is a color graphics file in a class object 
COLOR_GRAPHICS. Thus, messages are the interfaces between a class object (an application) 
and method objects (operations of the application). Messages are used against an application to 
specify types of operations the application can perform on the instance objects. The messages 
are generally in the form of a selector of an operation, such as PRINT, along with several 
parameters (e.g., STRINGS, NUMBERS, etc.). A message does not describe the implementation 
of a particular operation. It only represents the interface to the implementation of the particular 
operation. Thus, to find a particular operation (the method object) that is called by a particular 
message, one must not only examine the message but also the class of the instance object. To 
cause a specific action to occur, the message must be mapped to actual executable program code. 
This mapping occurs by finding the particular message which corresponds to the particular class 
of the particular instance and then finding the particular method which corresponds to the 
message supported by the class. The method represents the actual executable program code to 
implement the desired operation of the message on the instance. 

To understand Travis et al., it is essential that the technical differences between a class 
and an object be made. A class is a descriptive tool used in a program to define a set of attributes 
or a set of services (actions available to other parts of the program) that characterize any member 
(object) of the class. Program classes are comparable in concept to the categories that people use 
to organize information about their world, such as animal, vegetable, and mineral, that define the 
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types of entities they include and the ways those entities behave. On the other hand, an object is 
an instantiation of a class and is capable of executing. But not a class because a class is a named 
collection of attributes and services, which is not capable of executing. Travis et al. misuses the 
word "class object" and "method object" to mean a "class." For Travis et al., the term "instance 
object" means "object" in the traditional sense that an object is an instantiation of a class. See 
column 6, lines 31-42, among other places, where Travis et al. redefines the meanings of the 
term "object." 

The implication of these technical differences is huge. For example, Travis et al. teaches 
that "[t]he class ... would then be the class for several instances, but the instances are not ... 
managed by the object-oriented architecture." See column 9, lines 14-16. As another example, 
Travis et al. teaches that "[t]he class database consists of two types of objects [which] are either 
classes ... or methods ...," See column 10, lines 33-34. Note that Travis et al. does not mention 
instance objects or data as being objects stored by the class database. As a further example, 
Travis et al. teaches that "[t]he global class database ... is not meant to store application instance 
data because preferably applications completely manage their own sets of application instance 
data." See column 13, lines 55-60. The implication of this is that no instance objects are stored 
by Travis in the global class database. But there is more. Travis et al. teaches the following: 

The loader/unloader software component... is activated by a user 
wishing to transfer class information in local class database... to 
the global class database... The transfer makes information 
previously accessible only to the platform accessible to all network 
users through class database. . . . Transfer of class information from 
the local class database... to the global class database is preferably 
achieved by sending class and method object definitions in an 
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ASCII format to the load/unloader software component... for 

loading into the global class database. 
See column 16, lines 32-48. 

If class objects and method objects are executable units, it is difficult to understand how 
they could be transferred in ASCII format from a local class database to a global class database. 
Thus, the class objects and the method objects of Travis et al. are textual in form and not 
executable. 

Summary of Nagashima et al. 

Nagashima et al. is directed to a system for enhancing reuse of software and its running 
speed. The system of Nagashima et al. includes an object-oriented programming supporting 
apparatus for coupling a plurality of objects, each having data and operation with each other. 
The supporting apparatus comprises a display means, an object coupling means, a hierarchical 
structure construction means, and a handler. Focusing on the display means, objects are 
displayed by presentation of a block, a data output terminal for expressing the capability of 
transferring data of the object to another object, a data input terminal for expressing the 
capability of receiving data from another object, a message terminal for expressing the capability 
of receiving a processing request from another object to execute a method. Each object can be 
represented by a hierarchical structure which permits one or a plurality of objects to exist in a 
single object, and in addition, displays a wiring for coupling terminals of a plurality of objects. 
Summary of Vicik 

Vicik is directed to a method for dynamically escalating locks on a shared resource. 
When the number of low granularity locks exceeds a plurality of escalation threshold parameters, 
allocated low granularity locks for a particular (process) are escalated to a higher granularity lock 
and thereby free the low granularity locks for re-use by other processes. The plurality of 
escalation threshold parameters permit more flexible tuning of escalation criteria as compared to 
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prior techniques. The escalation threshold parameters may be varied according to the needs of 
particular computing systems, performance criteria, or other considerations. 
The Claims Distinguished 

As discussed in greater detail below, the claims of the present application are clearly 
patentably distinguishable over the teachings of the above-cited references. The present 
invention is directed to provide an asynchronous programming environment, which solves or 
reduces problems associated with prior programming environments. Applicant's invention 
provides a dynamic object storage scheme for storing a set of objects, a dynamic dispatch 
scheme based on the set of objects, and an object recognition scheme to describe the set of 
objects. The dynamic object storage scheme stores the set of objects so that each object can be 
accessed as necessary by different threads within the asynchronous programming environment. 
The dynamic object storage scheme is dynamic in that objects can be created and removed as 
necessary during the execution of tasks within the asynchronous programming environment. 
The dynamic dispatch scheme is designed to invoke an action based on the plurality of objects 
stored by the dynamic objects storage scheme. The action that is invoked by the dynamic 
dispatch scheme falls into one of a plurality of categories. Action may be classified differently at 
different times. The plurality of categories of actions include three categories tactions needing 
precisely one object, actions needing more than one object, or actions not needing any object at 
all. Actions needing precisely one object include message handlers, and other actions that do not 
need any objects for the execution are generally used to create objects, such as default 
constructors and real-time routines. Actions that require multiple objects for the dispatch 
generally combine objects and perform tasks as designed by the developer. The object 
recognition scheme describes the set of objects stored by the dynamic objects storage scheme. 
The description of objects allows the asynchronous programming environment to determine 
whether a described object fits the needs of an application programming interface. In other 
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words, when an application programming interface is presented to the asynchronous 
programming environment, it is not always clear which objects in a depository of objects fit the 
presented application programming interface. The object recognition scheme of the present 
invention allows one or more objects to be identified, thereby determining the suitability of one 
or more objects to the requirements of the application programming interface. 

Regarding the claims, independent Claim 1 is directed to an asynchronous programming 
environment. The environment is recited as comprising a dynamic object storage scheme for 
storing a plurality of objects. The environment further comprises a dynamic dispatch scheme for 
invoking an action that belongs to one of a plurality of categories. The plurality of categories 
includes needing one object, needing more than one object, and needing no object. The 
environment yet further comprises an object recognition scheme for providing a description of 
each object of the plurality of objects. The description allows a determination of whether an 
object described by the description fits an application programming interface. 

Claims 2-4 are dependent from independent Claim 1 and are directed to further 
limitations of the environment described above. Claim 2 is dependent on Claim 1 and recites 
that in the plurality of objects as stored via the dynamic object storage scheme are accessible 
utilizing a recyclable locking mechanism. Claim 3 is dependent on Claim 1 and recites that the 
plurality of objects as described via the object recognition scheme, each comprises a series of 
tokens, and each token in tum relates to an attribute of the object. Claim 4 is dependent on 
Claim 1 and recites that the dynamic dispatch scheme provides for execution of objects based on 
unpacked-into-messages events. 

Independent Claim 5 is directed to a method, and the method is recited as comprising 
storing a plurality of objects via a dynamic object storage scheme. The method further 
comprises dispatching at least one of the plurality of objects via a dynamic dispatch scheme 
based on events from at least one of the plurality of objects. The dynamic dispatch scheme is 
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capable of invoking an action that belongs to one of a plurality of categories. The pluralities of 
categories include needing one object, needing more than one object, and needing no object. The 
method yet further comprises describing each of the plurality of objects utilizing an object 
recognition scheme. The object recognition scheme provides a description of each object of the 
plurality of objects. The description allows a determination of whether the object described by 
the description fits an application programming interface. Claims 6-8 are dependent from 
independent Claim 5 and are directed to further limitations of the method described above. 
Claim 6 is dependent on Claim 5 and recites that the act of storing a plurality of objects via a 
dynamic objects storage scheme comprises accessing one of the plurality of objects utilizing a 
recyclable locking mechanism. Claim 7 is dependent on Claim 5 and recites that the act of 
describing each of the plurality of objects utilizing an object recognition scheme comprises 
describing each of the plurality of objects as a series of tokens. Each token relates to an attribute 
of the object. Claim 8 is dependent on Claim 5 and recites that the act of dispatching at least one 
of the plurality of objects via a dynamic dispatch scheme comprises executing at least one of the 
plurality of objects based on unpacked-into-messages events. 

Independent Claim 9 is directed to a computer, and the computer is recited as comprising 
a processor; a computer-readable medium; and an asynchronous programming environment 
being executed by the processor from the computer-readable medium. The environment is 
recited by independent Claim 9 as comprising a dynamic object storage scheme for storing a 
plurahty of objects. The environment is further recited as comprising a dynamic dispatch 
scheme based on an event from at least one of the plurality of objects for invoking an action that 
belongs to one of a plurality of categories, the plurality of categories including needing on 
object, needing more than one object, and needing no object. The environment yet further 
comprises an object recognition scheme for providing a description of each object of the plurality 
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of objects. The description allows a determination of whether an object described by the 
description fits an application programming interface. 

Claims 10-13 are dependent from independent Claim 9 and are directed to further 
limitations of the computer described above. Claim 10 is dependent on Claim 9 and recites that 
the plurality of objects as stored via the dynamic object storage scheme are accessible utilizing a 
recyclable locking mechanism. Claim 1 1 is dependent on Claim 9 and recites that in the 
plurality of objects as described via the object recognition scheme, each comprises a series of 
tokens, and each token in turn relates to an attribute of the object. Claim 12 is dependent on 
Claim 9 and recites that the dynamic dispatch scheme provides for the execution of objects based 
on unpacked-into-messages events. Claim 13 is dependent on Claim 9 and recites that the 
medium comprises a piece of memory. 

Independent Claim 14 is directed to a computer-readable medium that has a computer 
program stored thereon for execution on a computer. The computer program is recited by 
independent Claim 14 as providing an asynchronous programming environment. The 
environment comprises a dynamic object storage scheme for storing a plurality of objects. The 
environment further recites a dynamic dispatch scheme based on events from at least one of the 
plurality of objects for invoking an action that belongs to one of a plurality of categories, the 
plurality of categories including needing one object, needing more than one object, and needing 
no object. The environment yet further recites an object recognition scheme for providing a 
description of each object of the plurality of objects. The description allows a determination of 
whether an object described by the description fits an application programming interface. 

Claims 15-19 are dependent fi*om independent Claim 14 and are directed to further 
limitations of the computer-readable medium described above. Claim 15 is dependent on 
Claim 14 and recites that the plurality of objects as stored via the dynamic object storage scheme 
are accessible utilizing a recyclable locking mechanism. Claim 16 is dependent on Claim 14 and 
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recites that in the plurality of objects as described via the object recognition scheme, each 
comprises a series of tokens, and each token in turn relates to an attribute of the object. Claim 17 
is dependent on Claim 14 and recites that the dynamic dispatch scheme provides for execution of 
objects based on unpacked-into-messages events. Claim 18 is dependent on Claim 14 and recites 
that the computer-readable medium comprises a Compact Disc Read-Only Memory (CD-ROM). 
Claim 19 is dependent on Claim 14 and recites that the computer-readable medium comprises a 
floppy disk. 

As noted above, the fourth Office Action rejected Claims 1, 3-5, 7-9, 11-14, and 16-19 
under 35 U.S.C. § 103(a) as being unpatentable in view of the teachings of Travis etal. and 
Nagashima et al. Claims 2, 6, 10, and 15 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable in view of the teachings of Travis etal., taken in view of the teachings of 
Nagashima et al., and further in view of the teachings of Vicik. As also noted above, applicant 
respectfully disagrees. The cited and applied references simply fail to teach all of the limitations 
of the independent claims, much less the recitations of many of the dependent claims. 

Focusing on Claim 1, there is no teaching or suggestion in the cited references for an 
asynchronous programming environment in the manner recited in Claim 1 . Claim 1 recites that 
the environment comprises a dynamic object storage scheme for storing a plurality of objects. 
The remaining recitations of Claim 1 are directed to a dynamic dispatch scheme for invoking an 
action that belongs to one of a plurality of categories. The plurality of categories are recited by 
Claim 1 to include needing one object, needing more than one object, and needing no object. 
Claim 1 also recites an object recognition scheme for providing a description of each object of 
the plurality of objects. The description allows a determination of whether an object described 
by the description fits an application programming interface. The cited and applied references 
have failed to teach the concept of a dynamic dispatch scheme for invoking an action that 
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belongs to one of a plurality of categories (which includes needing one object, needing more than 
one object, and needing no object), among other things. 

Travis et al. describes a mechanism where client applications can remotely invoke other 
applications by sending globally recognized (network wide) messages with parameters. Using 
the name of the message and information about certain parameters and certain preference 
information, one method object is selected from a database. Other information in the database 
can be used to locate and execute the actual code to implement the method object. The action 
represented by the message is resolved into one method object and executes as specified in the 
message. The Office has recognized this deficiency of Travis et al. by noting that "Travis is 
silent with respect to the plurality of categories that include needing more than one object." See 
the Fourth Office Action, p. 3, paragraph 3. 

In contrast, applicant's invention recites, among other things, a dynamic dispatch scheme 
for invoking an action that belongs to one of a plurality of categories. The plurality of categories 
includes needing one object, needing more than one object^ and needing no object. Whereas the 
system of Travis et al. invokes one method object in response to a message, the dynamic dispatch 
scheme of various embodiments of the present invention allows the invocation of an action that 
belongs to one of a plurality of categories, including needing one object, needing more than one 
object, and needing no object. Among other things, the system of Travis etaL has failed to 
invoke an action that needs more than one object. 

Travis et al. specifically states that in response to a message requesting a method 
invocation from an application or user, a client application determines the proper method to be 
invoked by retrieving information from a class database, comparing the retrieved information 
with user preferences, and selecting the proper method based upon the comparison. Server 
connection and startup processes locate a platform capable of executing code associated with the 
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selected method. In other words, the system of Travis et al. is not designed to invoke an action 
that requires muhiple objects. 

The system of Travis et al. completely lacks other features recited by the claimed 
invention. For example, the Office has failed to show and applicant is unable to find where 
Travis et al. teaches or suggests "a dynamic object storage scheme for storing a plurality of 
objects" as recited in Claim 1 among other claims. As discussed before, the system of Travis et 
al. stores classes but not objects. Travis et al. uses the structure of classes and the infomiation 
provided by the classes so as to allow an application from one platform to invoke a method of 
another application running on another platform. But no objects are stored by Travis et al. The 
confusion stems from the misuse of the word "object" by Travis et al. at times to mean "class." 

This confusion must be dispelled to understand Travis et al. To illimiinate, suppose for 
the sake of argument that the class databases of Travis et al. can store executable objects. It is 
difficuh to understand how an object compiled for the VMS operating system can executed on 
the MS-DOS operating system. Thus, no objects are stored or can be stored in the class 
databases of Travis et al. The reason Travis et al. uses the class databases is to allow a client 
application on one platform to invoke a function by a server application on another platform. In 
contrast, applicant's claimed invention recites "a dynamic object storage scheme for storing a 
plurality of objects." No dynamic object storage scheme is provided by Travis et al. which is 
contrary to applicant's claimed invention. 

The Office cited Nagashima et al. for the teaching of "a dynamic dispatch scheme for 
invoking an action that belongs to one of a plurality of categories, the plurality of categories 
including needing one object, needing more than one object, and needing no object" as recited in 
Claim 1 . This cannot be correct. The Office explained that the hierarchical structure discussed 
by Nagashima et al. somehow teaches the dynamic dispatch scheme that can invoke an action 
belongs to a category of needing more than one object. Nothing about the teachings of 
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Nagashima et al. has anything to do with a dynamic dispatch scheme as recited in Claim 1. Each 
object is spawned from a class, which potentially inherits its attributes and services from a 
hierarchical structure of classes. But an object is still one object. For example, a person is one 
person and it is ludicrous to view a person as comprising a plurality of persons. 

Given the defects of Travis et al. and Nagashima et al., there would be no benefit to 
combine Travis et al., Nagashima et al., and Vicik, each alone or in combination. Even if the 
combination were possible, which assumption applicant specifically denies, the combination still 
would not teach applicant's claimed invention. 

Clearly, Travis etal., Nagashima etal., and Vicik, alone much less in combination, 
teaches or suggests the subject matter of Claim 1. More specifically, none of these references, 
alone much in combination, teaches or suggests a asynchronous programming environment that 
has a dynamic dispatch scheme, which invokes an action that belongs to one of a plurality of 
categories (needing one object, needing more than one object, and needing no object), and an 
object recognition scheme, which provides a description of each object of the plurality of objects 
so as to allow a determination of whether an object described by the description fits an 
application programming interface, as recited in Claim 1 . 

As will be readily appreciated in the foregoing discussion, none of the cited and applied 
references teaches or suggests the subject matter of Claim 1. Specifically, none of the cited and 
applied references teaches an object recognition scheme in the manner recited in Claim 1. As a 
result, applicant submits that Claim 1 is clearly allowable in view of the teachings of the 
references. 

With respect to dependent Claims 2-4, all of which depend directly or indirectly from 
Claim 1, it is clear that the subject matter of these claims is also not taught or suggested by the 
cited and applied references, namely Travis et al., Nagashima et al., and Vicik, Claims 2-4 all 
add limitations that are clearly not taught or suggested by any of the cited and applied references, 
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particularly when the limitations are considered in combination with the recitations of the claims 
from which these claims individually depend. In summary, Claims 2-4 are submitted to be 
allowable for reasons in addition to the reasons why Claim 1 is submitted to be allowable. 

Independent Claim 5 is directed to a method, which recites an act for storing a plurality 
of objects via a dynamic object storage scheme. The method further recites an act for 
dispatching at least one of the plurality of objects via a dynamic dispatch scheme based on events 
from at least one of the plurality of objects. The dynamic dispatch scheme is capable of invoking 
an action that belongs to one of a plurality of categories. The plurality of categories includes 
needing one object, needing more than one object, and needing no object. The method of 
Claim 5 yet further recites an act for describing each of the plurality of objects utilizing an object 
recognition scheme. The object recognition scheme provides a description of each object of the 
plurality of objects. The description allows a determination of whether an object described by 
the description fits an application programming interface. For generally the same reasons 
discussed above with respect to Claim 1, applicant submits that the subject matter of Claim 5 is 
not taught or suggested by any of the cited and applied references, and thus, that Claim 5 is also 
allowable. 

With respect to dependent Claims 6-8, all of which depend directly or indirectly from 
Claim 5, it is clear that the subject matter of these claims is also not taught or suggested by the 
cited and applied references, namely, Travis et al., Nagashima et al., and Vicik, Claims 6-8 all 
add limitations that are clearly not taught or suggested by any of the cited and applied references, 
particularly when the limitations are considered in combination with these recitations of the 
claims from which these claims individually depend. In summary. Claims 6-8 are submitted to 
be allowable for reasons in addition to the reason why Claim 5 is submitted to be allowable. 

Independent Claim 9 is directed to a computer. The computer recites a processor, a 
computer-readable medium, and an asynchronous programming environment being executed by 
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the processor from the medium. The computer of Claim 9 further recites that the enviromnent 
comprises a dynamic object storage scheme for storing a plurality of objects. The environment 
yet further recites a dynamic dispatch scheme based on events from at least one of the plurality 
of objects for invoking an action that belongs to one of a plurality of categories. The plurality of 
categories includes needing one object, needing more than one object, and needing no object. 
The environment additionally recites an object recognition scheme for providing a description of 
each object of the plurality of objects. The description allows a determination of whether an 
object described by the description fits an application programming interface. For generally the 
same reasons discussed above with respect to Claims 1 or 5, applicant submits that the subject 
matter of Claim 9 is not taught or suggested by any of the cited and applied references, and thus, 
that Claim 9 is also allowable. 

With respect to dependent Claims 10-13, all of which depend directly or indirectly from 
Claim 9, it is clear that the subject matter of these claims is also not taught or suggested by the 
cited and applied references, namely, Travis et al., Nagashima et al, and Vicik, Claims 10-13 all 
add limitations that are clearly not taught or suggested by any of the cited and applied references, 
particularly when the limitations are considered in combination with the recitations of the claims 
from which these claims individually depend. In summary, Claims 10-13 are submitted to be 
allowable for reasons in addition to the reasons why Claim 9 is submitted to be allowable. 

Independent Claim 14 is directed to a computer-readable medium that has a computer 
program stored thereon for execution on a computer. The computer program is recited by 
Claim 14 as providing an asynchronous programming environment. This environment comprises 
a dynamic object storage scheme for storing a plurality of objects. The environment is further 
recited to include a dynamic dispatch scheme based on events from at least one of the plurality of 
objects for invoking an action that belongs to one of a plurality of categories. The plurality of 
categories includes needing one object, needing more than one object, and needing no objects. 
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The environment as recited by Claim 14 further includes an object recognition scheme for 
providing a description of each object of the plurality of objects. The description allows a 
determination of whether an object described by the description fits an application programming 
interface. For generally the same reasons discussed above with respect to Claims 1, 5, or 9, 
applicant submits that the subject matter of Claim 14 is not taught or suggested by any of the 
cited and applied references, and thus, that Claim 14 is also allowable. 

With respect to dependent Claims 15-19, all of which depend directly or indirectly from 
Claim 14, it is clear that the subject matter of these claims is also not taught or suggested by the 
cited and applied references, namely Travis et al., Nagashima et al., and Vicik, Claims 15-19 all 
add limitations that are clearly not taught or suggested by any of the cited and applied references, 
particularly when the Umitations are considered in combinations with the recitations of the 
claims from which these claims individually depend. In summary, Claims 15-19 are submitted 
to be allowable for reasons in addition to the reasons why Claim 14 is submitted to be allowable. 

The Third Request to Correct Inventorship Under M.P.E.P. § 605.04(r1 

Given that the second request made by the applicant was completely ignored by the 
Office, the Office is again notified of a typographical or transliteration error in the spelling of the 
inventor's name. The incorrect inventor's name of "Slovak Ondrej Such" should read "Ondrej 
Such." In the originally-submitted declaration of December 21, 1998, the name of the inventor 
in the present patent application is set forth as "Ondrej Such." The inventor's citizenship was 
incorrectly set forth as "Czech Republic." The incorrect citizenship designation "Czech" was 
crossed out and the correct citizenship designation "Slovak" was handwritten so as to rectify the 
incorrect citizenship designation. The Office incorrectly interpreted, as evidenced by the filing 
receipt received on January 28, 1999, that the name of the inventor is "Slovak Ondrej Such." 
Applicant respectfully requests that this incorrect name designation be changed to the correct 
name designation of "Ondrej Such." More particularly, applicant respectfully requests that the 
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Examiner have the Technology Center*s technical support staff enter the correct name 
designation "Ondrej Such" in the PALM database or other pertinent databases and print out a 
new bibliographic data sheet, which should be placed in the file wrapper of the present patent 
application. 

CONCLUSION 

In view of the foregoing remarks, applicant submits that all of the claims in the present 
application are clearly patentably distinguishable over the teachings of Travis et al., Nagashima 
et aL, and Vicik. Thus, applicant submits that this application is in condition for allowance. 
Reconsideration and re-examination of the application and allowance of the claims and passing 
of the application to issue at an early date are solicited. If the Examiner has any remaining 
questions concerning this application, the Examiner is invited to contact the applicant's 
undersigned attorney at the number below. 

Respectfully submitted, 

CHRISTENSEN O'CONNOR 
JOHNSON KINDNESS^^^^ 




D.C. Peter Chu 
Registration No. 41,676 
Direct Dial No. 206.695.1636 
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I hereby certify that this correspondence is being deposited with the U.S. Postal Service in a sealed 
envelope as first class mail with postage thereon fully prepaid and addressed to Mail Stop Amendment, 
Commissioner for Patents, P.O. Box 1450, Alexandria, VA 223 13-1450, on the below date. 
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